\documentclass{report}
\usepackage{amsmath}
\usepackage[french]{babel}
%\usepackage[latin1]{inputenc}
\usepackage{graphicx}
\usepackage[utf8]{inputenc}
\usepackage{setspace}
\usepackage{multicol}
\usepackage{verbatim}
\usepackage{amsfonts}
\usepackage{color}
\usepackage{listings}
\usepackage{mathtools}
\usepackage{amssymb}
%\usepackage{vmargin}





%\usepackage{subfigure}
%%%%%%%%%%%%%%%% Lengths %%%%%%%%%%%%%%%%
\setlength{\textwidth}{15.5cm}
\setlength{\evensidemargin}{0.7cm}
\setlength{\oddsidemargin}{0.7cm}

%%%%%%%%%%%%% Java Listings %%%%%%%%%%%%%
\definecolor{jbackground}{rgb}{0.85,0.85,0.85}
\lstset{language=Java, backgroundcolor=\color{jbackground}}

%%%%%%%%%%%%%%%% Variables %%%%%%%%%%%%%%%%
\def\projet{4}
\def\titre{Problèmes de masquage d'informations}
\def\groupe{3}
\def\equipe{1}
\def\coordinator{felwahbi}
\def\others{apottier, osribti, mhaddoun, youidani}

\begin{document}
%\setlength{\topmargin}{-50pt}
%\setlength{\textheight}{758pt}
%\setlength{\textwidth}{17cm}
%\setlength{\evensidemargin}{-25pt}
%\setlength{\oddsidemargin}{-15pt}

%%%%%%%%%%%%%%%% Header %%%%%%%%%%%%%%%%
\noindent\begin{minipage}{0.98\textwidth}
  \vskip 0mm
  \noindent
  { \begin{tabular}{p{7.5cm}}
      {\bfseries \sffamily
        Project n\0\projet} \\ 
      {\itshape \titre}
    \end{tabular}}
  \hfill 
  \fbox{\begin{tabular}{l}
      {~\hfill \bfseries \sffamily Group n\groupe\ - Team n\0\equipe
        \hfill~} \\[2mm] 
      Coordinateur : \coordinator \\
      Membres d'équipe : \others
    \end{tabular}}
  \vskip 4mm ~

  ~~~\parbox{0.95\textwidth}{\small \textit{Résumé~:
  Le but de ce projet est de mettre en oeuvre les techniques de masquage d'information permettant de restreindre la portée de certains élements
du code jugés inutile au client, en utilisant de nouveaux concepts de programmation orientée objet vus en cours.
 Le remaniement du code ne doit pas changer les fonctionnalités.} \sffamily

}
  \vskip 1mm ~
  
\end{minipage}

%\setstretch{2}
%%%%%%%%%%%%%%%% Main part %%%%%%%%%%%%%%%%

%%%%%%%%%%%%% partie 1 %%%%%%%%%%%%%%%%%%%%
%\input{partie1.tex}
\section*{Cinquième Itération: Des objets constants ça sert à quoi ?}
Dans la cinquième itération, notre premier remaniement concerne la classe EtatPassager.\\
Si la classe EtatPassager ne construisait pas d'objets constants, il faudrait une instance d'EtatPassager pour chaque passager, donc il
faudrait autant d'instances d'EtatPassager que de passagers. Avec des objets constants définis en tant que variables de classe
nous créons un objet de chaque type (\verb+ASSIS, DEBOUT, DEHORS+), donc un total de trois objets, 
dans ce cas, le changement d'un état de passager correspond à un changement de référence de l'attribut EtatPassager du
PassagerStandard.\\

Le but de cette partie est de minimiser le nombre d'instance nécessaire de la classe
EtatPassager.
En fait, à chaque fois que le programme modifie l'état d'un passager, il est obligé de créer
une nouvelle instanciation de la classe EtatPassager puisque cette dernière ne fournit pas
de méthode pour modifier l'attribut correspondant.
\begin{lstlisting}
public static final EtatPassager EP = new EtatPassager(Etat.DEHORS);
\end{lstlisting}  

De plus, l'attribut est déclaré d'une part avec le mot-clef final, ceci ne permet pas la réécriture après l'instanciation. Il y a alors autant
d'instances que de modifications. d'autre part en static 
car elles n'existent qu'en un seul exemplaire pour toutes les instances de la classe et sont utilisables sans avoir besoin 
d'instancier la classe.\\
Une solution est de construire des objets constants. Grâce aux variables de classe, il
suffira d'instancier trois objets pour représenter tous les états d'un passager.
Pour empêcher l'instanciation éventuelle provenant du client, la portée du constructeur
de la classe doit être déclaré en private.


\section*{Sixième Itération: Portée et dépendance de compilation.}

L'objectif de cette itération est d'étudier deux solutions afin de masquer convenablement les méthodes internes supposées être inaccessible au
client.\\

\subsection*{Une première Solution}
La première solution consiste à remplacer les interfaces par des classes abstraites,
on sera ainsi capable de modifier la portée des méthodes. Mais cette modification entraine une
recompilation du code client(la classe Simple). Par conséquent, elle est refusée par le client.

\subsection*{Séparer les méthodes}
Une solution pour éviter ce genre de dépendance est de séparer les méthodes utilisées
par le client et les méthodes internes. \\
Les méthodes allerArretSuivant(), aPlaceAssise() et aPlaceDebout() de l'interface Bus sont copiées dans une nouvelle interface 
Transport. De même manière pour l'interface Passager, les méthode montrerDans()et nom() 
sont copiées dans une nouvelle interface appelée Usager.
Ces méthodes se trouvent par suite dans l'interface publique (Transport, Usager) et dans l'interface interne (Bus, Passager). Le but de cette 
manoeurvre étant de bénéficier du mécanisme d'héritage multiple rendu possible par l'utilisation d'interfaces.\\

Les interfaces \textbf{Usager} et \textbf{Transport} sont publiques et accessibles au client, ce qui nous a permis de modifier la portée
des interfaces internes au paquetage (Passager et Bus), cependant un PassagerStandard est toujours accessible au client, donc publique
et cette classe implémente Usager mais également Passager. Les methodes de l'interface ne sont donc pas convenablement masquées
car malgré la portée interne au paquetage, Passager est implementé par un objet rendu publique donc accessible par le client
(De même pour Bus et Autobus). L'intérêt du paquetage en est réduit.\\

Prenons le cas de la méthode \texttt{monterDans(Transport t)}, cette méthode est appelée du côté client mais doit faire appel à des traitements internes 
que seul Bus est en mesure d'effectuer (méthodes déclarées dans l'interface interne Bus) alors que la variable \texttt{t} est de type \texttt{Transport}. 
Ainsi, les méthodes supplémentaires de \texttt{Bus} ne sont pas accessibles sur l'objet \texttt{t}, bien qu'elles soient présentes grâce à la déclaration initiale:
\begin{lstlisting}
Transport t = new Autobus();
\end{lstlisting}
C'est pour cette raison que nous transtypons notre objet.\\
\begin{lstlisting}
bus b = (bus) t;
\end{lstlisting}

Nous effectuons donc le transtypage vers \texttt{Bus} de la variable \texttt{t} afin d'indiquer au compilateur que l'on peut désormais accéder à ces méthodes.\\


\textbf{Remarque :} En général, cette pratique comporte des risques. En effet, si l'objet final ne correspond pas à un objet concret (n'implémente pas l'interface Bus), il y aura une erreur à l'exécution.

A ce stade de l'itération, notre projet correspond au diagramme de classe ci-dessous :

\begin{figure}[h!]
\begin{center}
\includegraphics[scale=0.5,angle=270]{diag1.eps}
\caption{Diagramme de classe du package Tec}
\end{center}
\end{figure}


\section*{Septième Itération: Quelle portée pour les classes concrètes ?}


Le mécanisme de portée de java offre deux manières de rendre ces méthodes internes inaccessibles en dehors du paquetage. Elles dépendent de la portée des classes concrètes PassagerStandard et Autobus : 
Nous devons fournir le service d’instanciation par une classe publique \textbf{tec.FabriquePassager} (ou \textbf{tec.FabriqueBus}) qui contient uniquement une méthode de classes \textbf{fairePassagerStandard()} (ou \textbf{faireAutobus()}). Chaque méthode de classe effectue l’instanciation de la classe concrète interne au paquetage.\\
Ces 2 methodes font appel au Design Pattern Factory (en français Usine ou Fabrique). L'idée est d'avoir une classe non instantiable 
avec une methode définie en static qui se chargera de l'instanciation et retournera un objet.
La classe exacte de l'objet n'est donc pas connue par l'appelant.\\
Dans notre cas nous utilisons une fabrique pour la classe Autobus, ainsi nous avons notre classe fabrique : \texttt{FabriqueAutobus} contenant la méthode :
\begin{lstlisting}
public static Transport faireAutobus(int placesAssises, int placesDebout)
\end{lstlisting}
Cette méthode retourne un Transport car le client utilise l'interface Transport pour créer un nouvel Autobus, en revanche dans 
le code de la fonction on retrouve un appel au constructeur de la classe Autobus.\\
De même pour la classe FabriquePassager, on y retrouve la méthode :
\begin{lstlisting}
public static Usager fairePassagerStandard(String nom, int destination)
\end{lstlisting}

Ainsi les classes \textbf{FabriquePassager} et \textbf{FabriqueBus} vont nous permettre de créer de nouveau PassagerStandard et Autobus sans faire proprement une instanciation à l'aide du mot-clef \verb+new+.\\
Un simple appel à leur methode static suffit à fournir ce dont nous avons besoin. Il est donc inutile d'instancier un objet de ces classes "Factory".


\section*{Diagramme}
Après introduction de notre classe abstraite et de la fabrique FabriqueBus, voici un des diagrammes de classe de notre projet.\\

\begin{figure}[h!]
\begin{center}
\includegraphics[scale=0.5,angle=270]{diag2.eps}
\caption{Diagramme de classe du package Tec}
\end{center}
\end{figure}
Le même travail a été réalisé par l'autre tandem en portant l'interface Passager en classe abstraite et définissant une fabrique pour instancier un passager. 


\section*{Boutez vos neurones}
\subsection*{Solution 1 : classe abstraite}
La première solution développée consiste à transformer
les interfaces (dont les méthodes sont manifestement impossibles à masquer à cause de leur portée publique par défaut) en
une classe abstraite non-publique et donc de portée interne au paquetage tec.\\
Lors de l'ajout d'une nouvelle classe concrète, il suffit simplement de la faire hériter de la classe abstraite concernée (Passager). 
Le mécanisme d'héritage empêche de restreindre la visibilité des méthodes pour une raison simple : si une classe restreint la portée d'une de ses méthodes héritées, alors elle ne sera plus en mesure d'assurer les fonctionnalités de la classe mère.

\subsection*{Solution 2 : Fabrique}
La deuxième solution propose quant à elle de créer une classe concrète publique "Fabrique" se chargeant de l'instanciation des classes masquées 
sans les rendre elles-mêmes publiques.\\
L'inconvénient de la deuxième solution est de devoir modifier le code utilisateur du paquetage: il faut
alors utiliser la fabrique pour créer les objets. La première solution ne nécessitait pas de changer le code client.
Ainsi, Le choix de l'usine doit donc être fait à la conception\\
Avec le design patern "Fabrique", lorsqu'on veut rajouter une nouvelle classe, il faut rajouter la classe Fabrique associée afin de pouvoir instancier la classe.
Il ne faut pas oublier de bloquer l'instanciation et passer la méthode de fabrication en static.
 

\section*{Conclusion}
Ces trois itérations nous ont permis d'observer et manipuler le masquage d'information, et tout particulièrement des méthodes, par l'intermédiaire des classes abstraites et des classes concrètes non publiques (avec utilisation du Design Pattern Factory).\\
De plus, la première itération a permis de nous familiariser avec l'utilisation d'objets de classe et d'observer de plus le résultat d'opter pour une création d'objet constant sur un projet.
\end{document}
%%%%%%%%%%%%% partie 2 %%%%%%%%%%%%%%%%%%%%
%\input{partie2.tex}


%%%%%%%%%%%%% partie 3 %%%%%%%%%%%%%%%%%%%%
%\input{partie3.tex}





\end{document}










